1. Field of the Invention
The present invention relates generally to communications traffic engineering, and specifically to a method and apparatus for estimating the call Grade of Service (GoS), as well as the offered traffic, for Voice over Internet Protocol (VoIP) calls at a Public Switched Telephone Network-Internet Protocol (PSTN-IP) network gateway.
2. Related Art
The deployment of commercial Voice over Internet Protocol (VoIP) services based upon the ITU-T H.323 standard is proliferating as a means to complete telephone calls at a reduced cost. This service is currently offered in a variety of scenarios, as illustrated in FIGS. 1A–1C. In one scenario, illustrated in FIG. 1A, telephone calls are established over the Internet starting from a PC 1 and continuing to a gateway 2 on the Internet. The gateway ‘bridges’ the call between the IP network 4 and the conventional public circuit-switched telephone network (PSTN) 3. An example of this scenario is the free VoIP telephone service offered by dialpad.com, Inc., (URL http://www.dialpad.com) which brings toll free long distance telephony to its customers, generating its revenues through advertising on the PC client.
In another scenario, depicted in FIG. 1B, intra-European mobile PSTN calls, instead of being channeled directly from a mobile telephone in Europe 11 to a stationary telephone in Europe 12, and incurring the applicable toll, they are re-directed to an Internet gateway 5, located in Europe, from there routed over the Internet to another Internet gateway 14 in the United States. The U.S. gateway 14 then dials back to Europe over the conventional long-distance PSTN network 15 and reaches the stationary telephone in Europe 12. In this scenario, the cost savings are attributable to arbitrage, i.e. the relative price fluctuation between long distance calls from the United States to Europe, and the cost of a telephone call from a mobile phone within Europe.
In a third scenario, shown in FIG. 1C, telephone calls originating within a private enterprise at a private telephone 21, routed through the enterprise's private branch exchange (PBX) 22, (i.e., a switching system owned or leased by a business or organization providing both internal switching functions and access to the public network), are bridged onto the Internet at an enterprise PSTN-IP gateway 23. The calls are then established via the Internet to a remote gateway 24, where the call is then bridged back onto the remotely-located local PSTN 26, entering that PSTN at a remote gateway 24 which is a local call's distance from the call's ultimate recipient telephone 25. In such a scenario, long distance costs are avoided.
Due to the fact that the Internet, at present, does not in general support any quality of service (QoS) guarantees, in order to provide commercial VoIP services it is necessary to continuously monitor the end-to-end QoS that is seen at the software application layer in order to (i) maintain an acceptable QoS, (ii) plan for equipment expansion as traffic volumes increase, and (iii) remain ahead of the traffic demands.
In providing VoIP service, there are four main application layer QoS measures of importance: the end-to-end IP packet loss ratio, the one-way end-to-end IP packet delay, the one-way end-to-end IP packet delay jitter, and the call grade-of-service (GoS). The first three measures are at the IP network layer. The GoS is a session layer measure, defined to be the probability that a new call attempt is blocked and lost. Thus, the lower the GoS, the lower the probability of the call getting blocked, and the higher the probability of the call getting through. A low GoS is desirable, and a GoS of zero denotes the ideal case where all calls always get through (which is only possible in general with unlimited channels being available). The GoS at a gateway becomes a factor whenever a gateway is involved in the establishment of the end-to-end VoIP call, as is the case in all of the example scenarios described above.
The development of an end-to-end application layer VoIP QoS monitoring system for a large commercial service poses a number of challenges. First, a desirable system should introduce a minimal amount of measurement overhead traffic, scale with the size of the network, and be cost effective. One solution for monitoring the loss ratio and delay jitter is to use the Chariot system provided by Ganymede Software (URL: http://www.ganymede.com/html/products/chariot/index.phtml). In this system, so-called endpoints are placed in the IP network and emulated VoIP calls can be established between the endpoints. The loss and delay jitter is monitored on each emulated call and the results are processed and presented by a ‘console’ application.
The monitoring of one-way delays also poses a challenge. The main difficulties here are the problems of (i) time-synchronizing geographically separated PCs or servers to within a few milliseconds and (ii) maintaining a low drift between them in order to make accurate one-way delay measurements. One possible solution is to use the GPS time signals to synchronize time between the geographically separated PC's or servers. This can be done by deploying GPS Stratum-1 time servers at various sites. A Stratum 1 clock has a long-term accuracy of 10E-11. Stratum 1 clocks are generally used for synchronizing a few master sites in a digital telecommunications network. The synchronized signals propagate the time standard throughout the network. While providing a solution, this method is expensive and does not scale with network size. Another possible solution is to measure round-trip delays using ‘ping’ and then estimate the one-way delays from the round-trip delay measurements. However, for the measurement of grade of service and offered traffic at a gateway bridging the Internet and a public switched-telephone network, ping is of no use since it does not provide any information regarding the number of available PSTN channels at a gateway.
The monitoring of VoIP call GoS also presents a challenge. A theoretical solution to this problem is to have call generators, such as, for example, the Abacus from Zarak Systems (URL: http://www.zarak.com/product.htm), present calls to the various gateways and sample the number of blocked calls. This solution, however, is expensive and cumbersome, and does not provide satisfactorily accurate results due to sampling variance. Another possible approach is to poll the gateway for information on failed or refused calls. The problem with such an approach, however, is that inbound offered calls from the PSTN side may never even reach the gateway if they are blocked at the gateway-PSTN interfaces; thus they may never even be counted as failed or refused calls. Yet another possible approach is to derive the GoS from the gateway call-detail records that are already generated by the system for accounting and billing purposes. This approach, too, suffers from the drawback that offered calls that are blocked at the gateway-PSTN interface may never even reach the gateway. Moreover, the transmission, storage, and processing of large numbers of call records would be a cumbersome manner of trying to derive the GoS.
Thus, to truly enable the large scale deployment of commercial VoIP telephony, what is needed is an efficient, noncumbersome, technically straightforward, and scalable solution for monitoring the GoS and the offered traffic for VoIP at PSTN-IP gateways in an IP telecom network.
There is a need, therefore, for an apparatus and method that provides a technically straightforward, scalable solution for monitoring the GoS and offered traffic for VoIP at PSTN-IP gateways in an IP telecom network.